Brought to you by EarthWeb
IT Library Logo

Click Here!
Click Here!


Search the site:
 
EXPERT SEARCH -----
Programming Languages
Databases
Security
Web Services
Network Services
Middleware
Components
Operating Systems
User Interfaces
Groupware & Collaboration
Content Management
Productivity Applications
Hardware
Fun & Games

EarthWeb Direct EarthWeb Direct Fatbrain Auctions Support Source Answers

EarthWeb sites
Crossnodes
Datamation
Developer.com
DICE
EarthWeb.com
EarthWeb Direct
ERP Hub
Gamelan
GoCertify.com
HTMLGoodies
Intranet Journal
IT Knowledge
IT Library
JavaGoodies
JARS
JavaScripts.com
open source IT
RoadCoders
Y2K Info

Previous Table of Contents Next


INTEGRATING HETEROGENEOUS DATA BASE SYSTEMS

Migrating legacy data bases to new generation architectures is difficult. Although it is desirable to migrate such data bases and applications to client/server architectures, the costs involved in many cases are enormous. Therefore, the alternative approach is to keep the legacy data bases and applications and develop mechanisms to integrate them with new systems. The distributed object management system approach in general, and the CORBA approach in particular, are examples of such mechanisms.

Although the major advantage of the CORBA approach is the ability to encapsulate legacy data base systems and data bases as objects without having to make any major modifications, techniques for handling the various types of heterogeneity are still necessary (see Exhibit 6-6-3). The CORBA approach does not handle problems such as transaction heterogeneity and semantic heterogeneity. However, the procedures used to handle the types of heterogeneity can be encapsulated in the CORBA environment and invoked appropriately.


Exhibit 6-6-3.  Encapsulating Legacy Data Bases

Handling Client Communications with the Server

A client will need to communicate with the data base servers, as shown in Exhibit 6-6-4. One method is to encapsulate the data base servers as objects. The clients can issue appropriate requests and access the servers through an ORB. If the servers are SQL-based, then the entire SQL query/update request could be embedded in the message. When the method associated with the server object gets the message, it can extract the SQL request and pass it to the server. The results from the server objects are then encoded as a message and passed back to the client through the ORB. This approach is illustrated in Exhibit 6-6-5.


Exhibit 6-6-4.  Client/Server Architecture


Exhibit 6-6-5.  CORBA for Interoperability

Handling Heterogeneity

Different types of heterogeneity must be handled different ways. For example, if the client is SQL-based and the server is a legacy data base system based on the network model, then the SQL query by the client must be transformed into a language understood by the server. One representation scheme must be transformed into another. The client’s request must first be sent to the module that is responsible for performing the transformations. This module—the transformer—could be encapsulated as an object. As illustrated in Exhibit 6-6-6, the client’s SQL request is sent to the transformer, which transforms the request into a request understood by the server. The transformed request is then sent to the server object. The transformer could directly transform the SQL representation into a network representation, or it could use an intermediate representation to carry out the transformation.


Exhibit 6-6-6.  Handling Transformation

The distributed processor could also be used to perform distributed data management functions. The distributed processor is responsible for handling functions such as global query optimization and global transaction management. This module is also encapsulated as an object and handles the global requests and responses. The response assembled by the server is also sent to the transformer to transform into a representation understood by the client. Response delivery is illustrated in Exhibit 6-6-7.


Exhibit 6-6-7.  Delivering Responses

Semantic Heterogeneity

If semantic heterogeneity has to be handled, then a repository should be maintained to store the different names given to a single object or the different objects represented by a single name. The repository could be encapsulated as an object that would resolve semantic heterogeneity. For example, a client could request that an object be retrieved from multiple servers. The request is first sent to the repository, which issues multiple requests to the appropriate servers depending on the names used to denote the object. This approach is illustrated in Exhibit 6-6-8. The response may also be sent to the repository so that it can be presented to the client in an appropriate manner. The repository could be an extension of the transformer illustrated in Exhibit 6-6-6. All the communications are carried out through the ORB.


Exhibit 6-6-8.  Handling Semantic Heterogeneity

SUMMARY

The CORBA approach is an excellent means of addressing heterogeneity—especially with respect to queries, languages, transactions, schemas, constraints, and semantics. However, although CORBA is useful for integrating heterogeneous data base systems, there are still several issues that need further consideration. For example, should a server be encapsulated as an object? How can data bases be encapsulated? Should an entire data base be encapsulated as an object or should it consist of multiple objects? Should stored procedures be encapsulated also?

Although there is still much work to be done, the various approaches proposed to handle these issues show a lot of promise. Furthermore, until efficient approaches are developed to migrate the legacy data bases and applications to client/server based architectures, approaches like CORBA and other distributed object management systems for integrating heterogeneous data bases and systems are needed.


Previous Table of Contents Next

footer nav
Use of this site is subject certain Terms & Conditions.
Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Please read our privacy policy for details.